Gekkan Dennou Club 147

home *** CD-ROM | disk | FTP | other *** search

/ Gekkan Dennou Club 147 / Gekkan Dennou Club - 2000.8 Vol. 147 (Japan).7z / Gekkan Dennou Club - 2000.8 Vol. 147 (Japan) (Track 1).bin / tools / pecls / pecls5.lzh / diary0.doc next >

Wrap

Text File | 1999-11-23 | 38KB | 740 lines

1999/10/3 3:51 別件の方が忙しくて、こっちの方に手が掛けられない。もしかしたら今月は全然進まないかも(;_;) 取り敢えず今日はリハビリを兼ねて、ソース公開に向けてFIXMEを埋め込む作業をした。あと、68030以降のキャッシュ問題について、loader.rの初めで全面的にキャッシュを禁止して、改めてCPUに合わせてキャッシュの設定を行うと言う方針だけは決めた。ただ、暫くはキャッシュ禁止状態で使用することになるだろうけど、ソース公開したら誰かが対応してくれるだろうと言うことで（笑）でもって、なんでキャッシュ禁止にするかと言うと、マシンによってキャッシュの状態がマチマチな可能性があるから。例えば、X68030や060turboみたいに IPL-ROM上にキャッシュ制御のコードがあると、既にキャッシュONで制御が渡ってくるかも知れない。逆に、Xellent30(s|PRO)やJupiterなんかだとROMは元のままなのでキャッシュはおそらくOFFだろうから。あ、Xellent30の場合、SRAMに専用プログラムを入れておくとキャッシュONで立ち上がるかも。と言う訳で、個別に対処するのは大変なので、取り敢えずその辺の設定は無視してキャッシュOFF で起動することにする。どうせ立ち上がって仕舞えば、キャッシュ制御は自分でやらないといけないのでこれでも問題無いハズ。もちろん、SRAMを見て改めてキャッシュの設定はやるつもり。（作業優先度は低いけど） 1999/9/26 23:36 しばらく間が空いてしまった所為かだいぶ忘れて仕舞っている。今回独自でIPL を作成したのでloader.rの$c0000への再配置なんかせずに直接$c0000へ読み込めば良いことに今更気が付いた。この対処はそれ程手間ではないので、まずはそこから直していくことにしよう。 1999/9/13 1:58 あれ？CPUタイプのチェックルーチンでMC68000と認識された時の、分岐先の最後がrtsで終わってないぞ（爆）これだと、そのままデータ領域に突っ込むのでむちゃくちゃ危険なんですけど(^^;;;;; って事で速攻で直しました。あと、これまで対応してなかったMC68020とMC68060 もちゃんと区別するようになったはずです。(NetBSD/X68kのソースを参考にしました) あと、これまで適当に処理している部分が後で判るように、「FIXME」と言うコメントを少しづつ埋め込む様にした。と言うか埋め込み始めた。この辺もソース公開に向けてぼちぼち整理して行かないと駄目だな。 1999/9/8 1:13 なんと言うか、何処から手を付けて良いのか迷ってしまうほど、やらないといけない事が多すぎて結局、殆ど手を付けてなかったりする。取り敢えず、タスクのローカールヒープを持たせるために、boot.cnfの書式にヒープサイズのフィールドを追加。でもって、boot.cnfを読み込むloader.r側も対処した。今のところ本人の希望として今後実現したい機能を上げておく。出来れば、最初の幾つかは次回のリリースに含みたい。　・タスクローカルヒープ　・プリエンプティブなタスク切り替え　・ランデブ機能（name.srvの様な特に非同期動作を必要としないものはこっち　　に置き換えたい）　・humanfs.srv 　・タスク起動　・P-thread 　・ソースの公開　・key.drvのネイティブ化　・text.drvのネイティブ化ただ、例によってそううまく事が運ぶとは思えないので、実は単なる覚え書きかもしれない(^^; 1999/9/6 1:51 LEVEL 3 loader.rのタスクの起動部分でポカミスを発見。ポインタのポインタでないといけない部分がポインタになっていた。せっかくgccが警告を出してくれているのに、気が付かなかったとは、我ながら情けないっす。これは直したお蔭かどうかははっきりしないもののウチのXellent30マシンで起動するようになった。と言うか、試験用に使用していたEXPERTの電源が死亡してしまった。フロントスイッチを入れたら「バシッ」とか言ってヒューズが切れてしまったので、そのマシンでは確認出来なくなってしまったのです。このEXPERTには満開製作所のATX 電源キットを使用して250WのATX電源を接続して有ったのっだが・・・。 250Wの電源でヒューズが飛ぶとはどういう状況なのだろう？もしかして、何処かショートしているのだろうか？ちょっと心配である。と言う訳で、暫くは（別の要因もあるけど）開発効率が下がると思われるので、ここでリリースすることにする。色々やり残しは有るが、少しづつ進歩している（ハズな）ので暖かく見守って欲しい。 1999/9/3 1:08 あーあ、９月になっちゃった。なんだか、ウチのXellent30マシンでも動かないので、68040や68060マシンでも動かないんだろうなぁ。（因みに68000マシンでは動いてます）とりあえず今日は、console.srvで画面切り替え時に無条件で１画面分を再表示させていた部分を、文字の有る部分だけに最適化する処理を加えてみた。おかげで、画面切り替えが前よりはキビキビと動くようになった。LEVEL-2とはあんまり変わってないけど、そろそろリリースするかな。 1999/8/30 0:32 今のところ、MC68030以降での動作不良だが、やっぱりキャッシュ周りの様な気がする。一応、キャッシュの管理をもう少し細かく出来るように関数を分けてみたのだが、中身はまだ出来てなかったりして（笑）所で、気になったのが、68040や68060を登載したマシンの場合、マシン起動時に IOCSコールはキャッシュに対応しているのだろうか？ Humanの場合でも、IPLがHUMAN.SYSを読み込むのはIOCSを使う訳だから、キャッシュは制御（OFFにするとかクリアするとか）されてなければちゃんと動かない気がするんだけど・・・。 1999/8/28 5:03 これまで結構煩雑だったインストール方式を改善した。基本的にはこれまでと変わらないのだが、FDのイメージファイルを使用する様にしたので、若干アーカイブのファイルサイズが大きくなってしまった。まぁ、今後コマンド類が増えていけばそれ所の騒ぎじゃないので問題無かろう（それより、この開発記の大きさの方が問題有るかも）さて、区切りも良いことだしここらでLEVEL-3のリリースをしようかなぁ。それとも、今一番CPU時間を浪費しているキーボードドライバをネイティブに改善してからの方が良いかなぁ。どっちにしても、もう寝よう。今日オフが有るし。 1999/8/26 0:59 昨日やり残したIPLは、思ったよりあっさり動いてしまった。FDの直接読み込みと書き込みツールは既に有るので、次回のリリースからはフォーマットしたFDを準備してもらって、FDイメージを書き込むだけでブートディスクが作成出来るようになるはずである。これで、FLOAT2.drvを除いて全部自前で揃えたことになる。あと、MC68030以降で動作不良の恐れの有る部分を発見。それは、割り込みベクタを設定している部分なのだがIOCSを使わずに、直接アドレスを書き込んでいる。割り込みベクタの変更は一種の自己書き替えに相当するので、キャッシュをフラッシュしてやらないとコードキャッシュやデータキャッシュのコピーバックが残っていると古いアドレスに飛んでしまうと考えられる。これで、前回動かないと言われた68060マシンで動いてくれると良いのだけれど。 1999/8/25 0:48 だいぶ安定しては来ているのだが、なぜかMC68030マシン（Xellent30s）だとおかしな挙動を示してしまう。特別、MC68030で問題になるような部分はないハズなのだが・・・もう少し調べてみないとだめだな。でもって、いきなりだけどIPLを書き初めてしまった。それもC言語で（爆）FDD 専用ではあるが、なんとか512byteに納めることが出来た。って、出来上がってからフト思ったのだが、もしかして1024byteまで使っても良かったのかな？まぁ、動いているみたいだから良いや。でも、まだloaderの読み込みまで行ってなかったりして（動いてないとも言ふ）なんとか、この辺の問題を解決して9月頭頃には次のリリースをやりたいもんだ。 1999/8/24 2:19 FIFOオーバーフローの改善に成功。まぁ、判ってしまえば至って当然のことな訳だけど、そこに行き着くまでがなかなか難しい物なのである。まぁ、それが楽しいとも、プログラミングの醍醐味とも言うんだけど（笑）で、何をしたのかと言うと、asm("stop #$2000")の１行を追加しただけだったりして。まぁ、追加した場所がアイドルループの部分でUnlock()、Lock()と連続している所要するに以下の部分な訳だ。 while(1){ Unlock(); asm("stop #$2000"); /* これがミソ */ Lock(); if( (task=(volatile TASK_INFO*)_lnkRDY.top) ){ ・・・・ } } /* end of while */ まぁ、良く見てみれば、割り込みが受け付けられる時間が極めて短い事に気が付くハズだけど、こんな事に何日も費やしてしまう辺り、まだまだ修行が足りないと言う事なんだろうなぁ。 1999/8/23 1:28 なんとかdly_tsk()を使った状態でも暴走しないようになった。原因は、プリエンプティでないのに、割り込み処理で_currentTaskを変更してしまったために、実際のコンテキストとカレントタスクとの整合性が取れなかったためにおかしくなっていた・・・と思われる。そろそろ、プリエンプティブで無い事に由来する弊害が目だってきたので、もう少し安定したらプリエンプティブ部分も実装することにしよう。今、気になっているのは割り込み処理のFIFOオーバーフローなんだが、相当数がバッファ・オーバー・フローで失われている(^^;; これの原因がIOCS処理部分でのdis_dsp()/ena_dsp()間の割り込み処理禁止時間が長い所為ならデバイスドライバをネイティブに置き換えることで改善出来るハズなのだが、どうなんだろう。あ、そうそう。dly_tsk()でキー入力の監視を行うようになったのでCPU稼働率はかなり激減した。少しはマルチタスクらしくなってきたかな？ 1999/8/19 1:45 昨日動いたと思ったら、デバッグ用にdly_tsk()をrot_rdq()にしたままの状態だった。これじゃ動いて当たり前（爆）と、言う訳でdly_tsk()にすると前よりましになったものの、条件によって動きかたがマチマチになった。console.srvまでで止まる時もあれば、pshの起動後コマンドを受け付けてから止まることもある。この症状は間違いなく割り込み関係だな。明日もうちょっと調べてみよう。 1999/8/18 1:40 昨夜マシンの電源を落とした後に、フト完全なIdle状態から割り込みによりReady タスクが発生した時に問題が有ることに気が付いた。でもって、今日試した見たところdly_tsk()がちゃんと機能するようになった。あと、各プログラムのLEVEL 管理が判らなくなりそうなので、リリース毎の各プログラムのLEVELを記録する様にした。 1999/8/17 0:09 おおっと。開発記の記録を忘れてた。ほんとだぞ。なんにもやってなかった訳じゃなくて、単に記録を忘れてただけなんだから、間違えないように（笑）で、何をやってたかと言うとdly_tsk()が無効になってた（これの所為でキー監視タスクが待ち状態にならなくてCPU時間を浪費してた）のを修正しようとしてました。んが、どうやらシステムのLockがうまく行ってない様な気がする・・・このバグは根が深そうで、なかなか進展しないのです。困ったこまった。 1999/8/6 20:52 　ガビーン！！マルチコンソールにしてから、やけに表示が遅いと思ったら、後から追加したバッファリング処理が働いてなかった。どうりで遅い訳だ。バッファリング処理が動くようになると、マルチコンソールを入れる前とほぼ同程度の速度になった。まぁ、これ位なら我慢出来るだろう（笑）　更に、割り込みFIFO超過破棄数があまりにも多すぎる・・・。それ以前に遅延処理の方が多いのも問題だなぁ。って事で色々と調べてみたところUnlockされてなひ（爆）そこを直したところ、多少は改善されたもののそれでも遅延数の殆どが破棄されている。他にもなんかあるのかなぁ。 1999/8/5 1:04 LEVEL 2 　なんか本能の命じるままにコードを書いてたらfdd.drvが出来てしまったらしい（笑）まぁ、IOCSベースなので簡単に出来て当たり前なんだけど。やっぱり、調子良く進むと気持ち良いっす。でもって、何を血迷ったのかWWWページを開設することにしてしまった。相変わらず行き当たりバッタりではあるが、いつもの事と言うことで。ちなみにアドレスはやたら長ったらしくて「http://www.geocities.co.jp/SiliconValley-PaloAlto/7276/」でふ。そのうちこのPECLSやら、過去のフリーソフトなんかも載せる予定だが、4MBなんてあっと言う間な気がしないでもないぞ。それ以前にHTMLが判らないからそっちの勉強が先かな。 1999/8/3 1:15 　ついにマルチコンソールが稼働！！ただし、かなり手抜きな部分が多いので洒落にならないぐらい遅いのだが。原因は、1文字毎にパケットを組み立てて text.drvに送っているからだと思い、バッファリングをする様にしてみたのだが、改善は見られなかった・・・？？？と、言う事は、仮想画面の描画処理が思ったより重いのが原因のようだ。まぁ、デバッグ用のコード入れまくりなので当然と言えば当然なのだが、text.drvの出力がROMのIOCS（爆）と言うのも無関係ではないだろう。いずれは改善すると言う事で。　そんな事よりもシステム起動時の画面出力が最初のコンソール画面に引き継がれないので結構違和感が有る。これを解決するためにはloaderに取り合えずの text.drvタスクを組み込むと言う手が考えられる。ただ、loaderの自己消滅と関連して結構めんどくさそうだなぁ。 1999/8/1 0:02 　あぁ～～あ。8月になっちゃった。L-2のリリースを7月中にと思ってたのに・・・で、やっぱり問題はマルチコンソールだったりする。前回動かなかった原因は、情けないメモリーリークで有ることが判明。しかし、いまだpshのプロンプトまでたどり着けない。キー入力も受け付けないところを見ると、表示だけの問題と言う訳でもなさそう。どっちにしろ、もう暫く掛かりそうなので、L-2のリリースを8月中と言うことにして、fdd.drv辺りとhumanfs.srv、exec.srv周りも盛り込んでみようかな。って、それは欲張り過ぎか(^^; 1999/7/26 23:28 　うーむ。console.srvのマルチコンソールを取り敢えず作ったけど全然動かんな。まぁ、いきなり動いたらそれはそれで気味悪いけど（笑）あと、console.srv に連動してtext.drvのリクエストコードも多少手を加えた。もしかしたら、この辺の修正をミスったのかも。どっちにしても色々いじったので何処が原因で動かなくなったのか判らなくなったので、１つづつ地道にチェックして行くしかないかな。できれば、今月末に次のリリースを行いたいのだが・・・ 1999/7/21 1:53 　なんか日にちが開いてますが気にしないように(^^;それはともかく、取り敢えずではあるが、READYキューへの登録時に優先度を考慮する様にした。ただ、現在の実装では全リストを対象に優先度を比較していくので、タスク数が増えるとキューへの登録処理に時間が掛かることになる。これはそのうち、優先度毎にリストを作成する様にして処理の高速化を行う予定。　あと、console.srvにマルチコンソールをサポートするための仮想画面管理処理を追加した。と、言うか追加している。現在の実装では１文字表示する毎に text.drvに文字表示を要求するようになっているが、バッファリングし、文字列として要求した方が効率は良いハズだ。ただ、出力先がtext.drvではなく、sio.drv 等のように低速の通信路を経由する場合は、１文字毎に要求した方が全体的な効率は上がる可能性があるので、このバッファリングはオプションで切り替えられる様にしておいた方が良さそうだ。　あ、そうそう。先日実装したref_tsk()を使う物をpshに組み込んでテストしないといけないなぁ。 1999/7/15 1:33 　今日は特になにかを作ったと言う訳ではない。ここ数日の変更に対して実際に動作するかを確認した。チマチマしたバグを取って、なんとか動くようになったのがこの時間なので、今から何かすると言う訳にもいかない。　話しは変わるが、なんとかPC-UNIX上でクロス開発できないか調査中。実行ファイルの形式をELF形式に出来ればなんとかなりそうなんだけど、ELFのリロケータブルフォーマットってHuman68kの.xファイルのリロケート情報みたいな物なんだろうか。使えそうならローダーの変更だけで移行出来るのだが・・・ 1999/7/14 1:43 　name.srvが管理する情報フィールドをID×2からID×4に拡張した。あと、参照系のシステムコールを幾つか実装しようと思ったけどref_tsk()だけで力尽きてしまった（笑）残りは後日と言うことで。「今回の実装コール」 ref_tsk() 1999/7/13 1:33 　なんかディレクトリィを深く掘った所為か起動に時間が掛かるような気がするので、loader.xにディレクトリィキャッシュを付けてみた。気の所為程度は改善されたような気がする。　マルチコンソールのために、key.drvのrawモードでシフト状態も通知する様にし、console.srvにコンソール切り替え機能を実装。と、言うかconsole.srv自体には既にマルチコンソールの管理自体は入ってたりする。単に切り替え機能だけ実装してなかっただけだけど（笑） 1999/7/12 0:41 　気が向いたのでMC68030以降に対応してみた。対応と言ってもtrap周りの処理で例外フォーマットも考慮する様にしただけなので対した手間じゃ無いですが。ただし、今後プリエンプティブなタスク切り替えを実装した場合は、更に要注意なので、気を付けねば。　あと、先日実装したシステム情報のシステムコールのデバッグを行った。まだちょっと怪しい値を返しているような気もしないではないが、なんとか動くようになった。　MC68030以降でも動くようになった事だし、マルチコンソールを実装したら次のリリースをするかな。　そうそう。ふと思い付いてITRONのWWWを見てきたらITRON4.0の規格書が出てるぢゃないですか。う～～～む。これは、なんか適当なタイミングで3.0から4.0へ移行しないといけないかな。ざっと見たところオブジェクトの動的確保周りが規格に取り込まれたようだ。 1999/7/10 1:6 　割り込みからのシステムコール周りを整備。でも、まだ割り込みからのシステムコールは１つも実装してなかったりする（笑）　Makefileを充実。これまで個別のディレクトリィまで降りていってメイクしていたのを上の階層からgmakeすることで下の階層全てをメイク出来る様にした。でも、全部とかやると時間掛かるんだよな。　P-Threadライブラリだけど、イベントフラグだとカーネルの資源を消費するので、slp_tsk()、wup_tsk()で実現する様にした。だって、カーネル資源を使うと、タスク終了時に返却しないといけないから面倒なので。やっぱり、ITRONは組み込み向けだけあって、動的なタスクの管理関係が弱いなぁ。 1999/7/8 2:15 将来の標準ファイルストリームの事を考えてname.srvが管理する情報をIDから FileHandleに変更した。これにより、１つの名前でIDを２つ保持出来るようになった。それに伴って、key.drvのキーイベントにrawモードとcookieモードで別のパケットを返す様にした。こうすることで、通常は別のタスクからの文字列表示をそのままキー入力として受け入れることが出来るようになるので、パイプ処理が実現し易くなるハズ。　前回書いたシステムコール処理関数の戻り値の設定をちゃんと行う様にした。あと、せっかく計測する様にしたCPU稼働率が見られるようにシステムコールを追加した。　それとP-threadだが、このライブラリにはC-threadと異なり明示的にライブラリを初期化するコールが無いようだ。これでは、ルートスレッドに対してスレッド管理領域が確保されてないので色々と面倒な事になりそうだ。なので、P-threadを使う場合は、別のスタートアップルーチンを使うような小細工が必要だろうと思う。まぁ、たいした手間じゃ無いけど。それにしても、この「開発記」はサイズが増えるのが早いなぁ（笑）もしかしてプログラム書くより、こっち書く量の方が多かったりして（うっ・・・笑えん）「今回の実装コール」 ref_sys() 1999/7/5 2:38 　P-threadの実装上必要になったのでイベントフラグの実装を行った。そう言えば、各同期オブジェクトには初期化用のパケットが有ったけど、今のところ殆ど無視していたりする、この辺もちまちま作り込んで行く必要があるな。　あと、システムコール処理関数のreturnでシステムコールの処理結果を返すのは問題があることが判明。この修正は結構手間取りそうなので、そのうち気が向いたら対応しよう。どうせ、問題が出るとしたらexd_tsk()の場合ぐらいなので、急ぐ必要はないや。　あと、気になっているのが68030以降への対応。多分、trap処理周りだけだと思うのだが後回しになってたりする。そんなに難しくないハズなので、とっとと片付けてしまった方が良いかも知れないゾ。「今回の実装コール」 cre_flg() del_flg() set_flg() clr_flg() wai_flg() 1999/7/3 1:03 　フト思い付いてカーネルのCPU稼働率を検出する処理を入れてみた。まぁ、アイドルループの前と、レディタスクの発見時との時間から空き時間を集計するだけの簡単な代物だけど、カーネル稼働時間と比べればシステムの負荷が算出出来るので結構使えるかも。って、そのためにはその情報を引き出すシステムコールが必要な訳だけど、これはそのうち実装しよう（笑）　P-threadのライブラリをぼちぼち作り始めた。基本的なシステムコールが揃っているので、これらを組み合わせれば結構簡単に実装出来そうだ。ITRONではスレッドと言う概念がないので、システムコールレベルでは、タスクもスレッドも同じだけど、OSとして見た場合は全く別物として管理しないといけないので、この辺の実装が頭の痛いところだ。一応、exec.srvがその手の管理を行う予定。　そうそう、ITRONにはスレッドもタスクも同じなので、計らずも１対１モデルになるのであった。ヂュアル・プロセッサ（POLYPHON!?）なら効率的に動作するハズだ。カーネルが対応してればだけど。 1999/7/2 1:13 LEVEL 1 　予告通りLEVEL-1のリリースである。ホントはマルチコンソールまで実装してからリリースしたかったけど手間取りそうだったので、次回に持ち越しとした。取り敢えず、今回のリリースの目玉は、pshの全ての入出力がconsole.srv経由で keyboard.drvとtext.drvを使用して行われることなのだ。依然、IOCSベースではあるが、I/Fさえ決めておけば本当のドライバと差し替えても問題無いハズなので、大きな前進と言える・・・かな。　今後の予定としては、console.srvのマルチコンソールとか、fdd.drv、exec.srv とか色々有るので、考えると気が遠くなるので敢えて考えないことにする(^^;; 1999/7/1 3:04 　ホントはLEVEL-1は6月中にリリースしたかったんだけど、コンソールサーバー周りがまだ未整理なので、今週末まで延期することにした。それ以前に全然前回と見栄えが変わってないのが情けないっす。まぁ、内部的には結構かわったんだけど・・・。　でもって、psh内でキー入力をIOCSコールで行っていたのをconsole.srv経由の keyboard.drvで行えるようになった。とは、言ってもkeyboard.drv内では、未だにIOCSを使ってたりするのだが(^^; 　後は、画面の表示の方もconsole.srvを経由してtext.drvに行わせるように出来たら取り敢えずリリースしようと思う。　あ、そうそう。先日のselect()の件だが、ITRONの仕様書をひっくり返したところ、dis_dsp()と言うコールが有ることを発見。これは、一時的にタスクの切り替えを遅延する（禁止する訳ではない）ものなので、一種の排他制御が行えるようだ。これを使えばいちいちセマフォを使わなくても気軽にロックが掛けられる訳だけど、ネストは出来ないそうなので、やっぱりセマフォでやった方が良さそうだ。「今回の実装コール」 dis_dsp() ena_dsp() 1999/6/30 3:41 　う～～む。困った。コンソールサーバなんだけど、こいつは、アプリとデバイスドライバとの両方からのメッセージを同時に待つ必要が有る訳なんだな。だけど、ITRONにはUnixで言うところのselect()が無いので、複数のメイルボックスに対して待ちに入ることが出来ない訳で困ってるのだ。まぁ、むりやり複数のスレッドを立ち上げて個別に待ち状態にはいる手も有るけど、複数のメイルボックスに対して待ちが出来るシステムコールを独自で追加しようかと考え中。　一般的にはメッセージパケット中に発信元やパケット種別を入れることで区別する訳だけど、それだとシステム全体での整合性を保つのが難しいので、独自仕様を追加する方針も考えている。さぁて、どうするかなぁ。　ま、動くことが先決なので、別スレッドで取り敢えず実装しておこう。 1999/6/28 1:26 　昨日色々手を入れ、コンソールサーバーもコンパイルが通るようになったので、今日は試しに動かしてみた。すると、ネームサーバーの起動で止まってしまうぢゃないの(;_;)デバッグ出力を頼りにあちこち調べてやっとの事で、先日やった排他制御をシステムコール入り口に移動した時のエンバグである事が判明。　まぁ、今日は雨だったとは言え、このバグで一日潰れたのはやっぱり情けないなぁ。精進せねば・・・。 1999/6/27 4:10 　タスクの状態としてこれまで設定していたTTS_RUNを付けない様にした。どうせ、_currentTaskで判るし、ref_tsk()（まだ作ってないけど）で小細工すれば済むのでわざわざやる必要もないだろう。でもって、セマフォを実装した。全然関係無い話しだけど、何を勘違いしたのかセマフォの綴をsemafoと書いてたけど、実はsemaphoreが正しいようだ。と、言う訳で今回からはsemaphoreとなっているのでみんなも気を付けよう。　今回のセマフォの実装で最低限のシステムコールは実装出来たことになるのかな。今後はサーバーやドライバ等の作成で必要になった段階で順次実装していくことになるかな。これはきっと近代的なオン・デマンドとやらに違いないぞ（笑）「今回の実装コール」 sig_sem() wai_sem() preq_sem() 1999/6/25 0:16 　ちょっとバテ気味。今日はあんまり大したことやってない。取り敢えず、割り込みに対する排他制御をチマチマやるのをやめて、システムコールの出入口で一括して行う様にした。ほんとは割り込み処理の応答性を考えるとチマチマやった方が良いのだが、現在の開発段階ではめんどくさいだけなので、この手の最適化は後の楽しみに取っておくことにする。　関係無いけど今年の夏はなにやら忙しくなりそうだ。本業の仕事と、アルバイトのソフトの仕事、そんでもってこれの開発に、週末にはキャンプツーリングとまぁ、その他色々と・・・。でも、私の思考もリアルタイムなので、優先度に従って進める訳なので問題無いかも。当然、一番低いのは本業なのだ（笑） 1999/6/22 0:17 　割り込み処理の中身を実装した。これにより、dly_tsk()が使えるようになった訳なんだけど、暫定処置としてIOCSを使っている部分が多いため、プリエンプティブなタスク切り替えは暫くお預けだな。　例によって、割り込みでのタイムアウトチェックは非効率的な実装になっている。余力が出来たらリングバッファを使った、より効率の良い方式に修正せねば。　あと、昨日作った時間関係のシステムコールをテスト。pshにdateコマンドを追加して連続表示させてみたところ、どうやらそれなりにちゃんと動いているらしい(^^) 「今回の実装コール」 dly_tsk() rot_rdq() sus_tsk() 1999/6/21 2:43 　カーネルの時間関係のシステムコールを実装する前に時間に関する処理を組み込んだ。それにしても、ITRONの仕様だとSYSTIMEは48bitと中途半端でちょっと使い辛いなぁ。64bitならlong longで楽なんだけど。　取り敢えず、ライブラリとしてSYSTIMEとstruct tmの相互変換関数を追加した。まぁ、これは後々のPOSIX準拠(するのか!?)のための布石なんだけど。　あと気になるのは、カーネルの周期割り込みをタイマーDで行っているが、これは将来的にタイマーCに変更したい。その為には、FDDドライバとかの周辺を整備しないといけないけど。それと、現在のget_tim()で得られる値は、カーネル起動時間から割り込みでカウントした時間なので、実際のRTCの値と違う可能性がある。この時間誤差の補正をどうするかが問題。　構想としては、１時間毎に補正するとして、RTCより進んでいたら割り込みを幾つか無視することで、遅れていたら割り込み時の処理を複数回行うことで合わせる様にしたい。んが、こんなのはも～～～～っと他の所が出来てからだな（笑）「今回の実装コール」 get_tim() set_tim() 1999/6/17 1:40 　システムコールの処理内に割り込みとの排他制御を組み入れた。あと、排他制御中の割り込み処理でのシステムコールを保持するFIFO処理を作成。っていうかー pecls libraryのソースから殆どそのまま持ってきた。ちょっと心配なのは、ヒープの確保や解放も排他制御のLock()、Unlock()内に有ることだ。メモリーの確保時や解放時には場合によっては結構な時間が掛かることが考えられるので、どうしたもんかなぁ・・・。　それと、コンソールサーバーの考え方に付いて、１セットの入出力デバイスに対して１つのコンソールサーバーを起動することにした。これは、マルチコンソールを考えると妥当な線だと思うのだがどうだろう。　そうそう、ライブラリを追加したのを忘れるところだった。ネームサーバーに対する登録と問い合わせの関数をliblow.aに追加した。(MailboxINameRegist、 MailboxIdGet) 1999/6/14 0:30 　コンソールサーバーに関しては、まだ考えがまとまらないので、気分転換に他の部分をちょこちょこいじった。取り敢えず、ネームサーバーについては現地点で一通りの機能を実装したので、これからしばらくは手を加える必要は無いだろう。あと、ネームサーバーと実行サーバーリクエストで、返答先IDが入ってないとエラーにしていたのを返答が必須でないリクエストの場合は正常として扱う様にした。　それにしても、あれやろうこれやろうと言ってるわりに、それとは関係無く適当に進めてる気がするなぁ（笑）まぁ、それだけやることが残っていると言うことで、勘弁してちょんまげ（死語） 1999/6/7 23:50 　そろそろコンソールサーバーも作りたいので、入出力のやり取りを考えてみるが、どうもうまい手が思い付かない。少なくとも、マルチコンソールを実現するために、仮想VRAMはコンソールサーバー上に持つ必要があるので、エスケープシーケンスの解析はコンソールサーバーでやらないといけないのは確かだ。　あとは、端末デバイスファイルを使った標準入出力の割り当て手順を考えないといけない。この辺をうまく取り決めておけば、りダイレクトやパイプの実現も手軽に実現出来るハズである。 1999/6/5 20:18 　結構間が開いているが、その間何もしてなかった訳じゃないぞ（笑）サーバーやドライバを作成してて、マルチスレッドを実現するために、それぞれでcre_tsk() とかやっていると、実行サーバーとの絡みも有って結構めんどくさい。　なので、その辺の問題をまとめて扱えるようにスレッドライブラリの導入を検討中である。もちろん仕様はPスレッドで有る訳で、その手の資料を勉強中だったりする。ただ、この本を読み終わるまで開発がストップするのもアレなので、そろそろ割り込み周りでも実装しようかと考えている今日この頃。　PECLS Libraryの時にも手間取ったけど、カーネルの排他制御と割り込みからのシステムコールによるタスクの起動は、明かにアクセスする領域がバッティングするので、リアルタイム性を尊重するためにも割り込み禁止期間は短い方が良い。なので、割り込みからのシステムコールをFIFOに貯める細工が必要になってくる。　あと、割り込みからのシステムコールは、事実上別のtrap番号が必要なので、その割り当ても考えねば。　そうそう、タスク毎のローカルヒープサイズの指定方法も考えておく必要が有るなぁ・・・。残件は上げ始めると切りがないのでこの辺にしておうこう(^^;;; 1999/5/26 4:54 　次はファイルサーバーとか言いながら、キーボードドライバを作成した。最低限の機能は実装したものの、このドライバにアクセスするタスクがまだ無いので、ちゃんと動くかどうかはまだ不明。それにしても、毎回色々直しているので修正履歴とか書けないのがちょっとアレだけど、まだ暫くはこんな感じかな。　と、言う訳でLEVELの割り当ては、有る程度安定するまでリリース毎になるのかな。　サーバーリクエストのリクエスト先IDを廃止した。理由は、この情報を保持するのは問題無いが、boot.cnfのネームサーバーへ登録するID名称との対応を取るのが難しいから。特に今後スレッドとかが出てくるとややこしくなるのが目に見えているので、思い切って廃止した。お蔭で、サーバーソースはもちろん、ヘッダーも修正することになったので、ローダーまで修正と言う・・・カーネル以外殆ど全部に手を加える羽目になってしまった。 1999/5/23 1:28 　まだ本腰は入れないけど、MC68000以降でも動作する様にするための手始めとして、キャッシュのフラッシュ処理を書いた。あんまり手元に資料がないので、自信はないけど、多分大丈夫だろう。68020、68030については、Motorolaの「ユーザーズ・マニュアル」を、68040についてはBEEPs氏の「X68/040turbo」を 68060については、「Oh!X復刊一号」を参考にした。各著者の方々に感謝します。　メモリープール関係の処理を整理。これによりローカルヒープが扱えるようになったハズ。あと、ついでにタスク関係の簡単なシステムコールも幾つか揃えた。小さな事からコツコツとって事で（笑）「今回の実装コール」 cre_mpl() del_mpl() ext_tsk() wup_tsk() 1999/5/21 2:33 LEVEL 0 　pshのコマンドを作成。これで、ちゃんとサーバーに問い合わせて一覧情報を取得するようになった。う～～ん。マルチタスク・システムっぽくなってきたぞ。あと、ユーザープログラム（サーバー、ドライバも含むけど）の標準スタートアップ・ルーチンをライブラリに入れる様にした。これで、main()は普通にargcと、 argvが参照出来るようになったし、malloc()、free()も使えるようになった。　ただし、まだローカルヒープが作成出来ないので、ライブラリの方はこの先手を入れる必要がある。それにしても、ローカルヒープとマルチヒープとの組み合わせをどうするかは今後の課題である。　ファイルサーバー作成の前に、実行サーバーをそこそこ片付けて\junk辺りにアップすることにした。知っての通り、システムの骨格どころか、背骨も出来てないので、ほ～～んとになんにも出来ないが、まぁ、反応を見ると言うことで。 1999/5/19 0:53 　ついにネームサーバーが動作を開始。とは言っても、基本的な部分だけなのでそんなたいした事ではないんだけど（笑）　前回の記録から日数が掛かっているのは、ネームサーバー問い合わせでアドレスエラーになると言うバグの追求に手間取った所為だったりします。　原因は取り敢えず対処でpget_blk()内部で呼び出しているHalloc()のIDに0を指定してしまっていたために、そのブロックが未使用と判断されていたと言う、例によって情けないバグでした。こんな事で３日も悩むなんて、我ながら情けない・・・(T_T) 　でもって、調子良く進み始めたので、実行サーバーのタスク管理部も少し作り込んでみた。実行サーバーが本格稼働するためにはファイルサーバーの存在が必要なので、まだまだだけど、タスク一覧とかメモリーの使用状況とかが有る程度把握出来るようになったのは進歩したと言えるかな。　ネームサーバーについては、外部との接点が非常に少ないので、最低限の機能は実装出来たことになる。実行サーバーのためにもそろそろファイルサーバー辺りも作り始めるかな。 1999/5/16 3:25 　ん～～む。バグが取れん。なんか、ネームサーバーの管理情報のアドレスがおかしいらしく、止まってしまう。昨日まではpsh.xまで動いてたので、それ以降に追加した部分に問題があるんだろうけど、幾ら見直しても判らない・・・　バグが取れない気分転換に、各ファイルの拡張子を以下のように整理した。カーネル .knl サーバー .srv ドライバ .drv アプリ (無し) 1999/5/15 4:14 　ネームサーバーをもう少し身の有る物にした。まだ完全じゃ無いけど、先日作ったsnd_msg()とrcv_msg()も、幾つかのバグを取ることで動くようになったラシイ。あと、PECLS標準シェルになるはずのpsh.xを取り合えずのチェック用として、幾つかのコマンドを実装した。ちゃんとしたシェルとしての機能を持たせるまでは、内部コマンドを色々追加して、それを使ってテストをするだろうから、最終的には作り直しになるかも（笑）　どっちにしろ、外部コマンドを起動出来るようになるためには、最低でも実行サーバー、ファイルサーバー、ディスクドライバが揃わないといけないので、まだまだ、まだまだ、まぁ～～だまだ先なので今心配する事でないな。 1999/5/12 21:57 　なんか、思ったより簡単にFLOAT2.drvが出来た。まぁ、DOSコールをIOCSコールに置き換えて、KEEPPRをslp_tskに変えただけ（笑）なので簡単な訳だけど。ちと、拍子抜け。とは言ってもタイトル画面が出るのを確認しただけなので、ちゃんと動くかどうかは、まだ判らなかったりして（笑）　他の部分が落ち着いたらその辺もチェックせねば。それはともかく、タスクの起動自体は出来るようになったので、ちゃんとしたマルチタスクを行うためにも、同期プリミティブの実装を開始した。最低限、メイルボックスとセマフォを実装しておけば、かなりの事が出来るのでその辺を優先的に組んでいく予定。まぁ、実際は優先度とか、プリエンプティブとか、割り込みとか、解決しないといけない問題がまだまだ山積みだったりする訳だけど、まずは動くことが先決と言う事で、結構いい加減な所が残っていたりする。この辺も追々直していかないとね。「今回の実装コール」 cre_mbx() del_mbx() snd_msg() rcv_msg() cre_sem() del_sem() 1999/5/11 22:53 　動かなかった原因が判明。まぁ、例によってしょ～～～もない事だった訳だけど、一応書いておこう。一言で言ってしまえば、「リンク後の位置とリンカに指定するファイルの順番とは必ずしも一致しない」って言うことであった。　ヒープ領域を確保するのに、サイズを指定したくなかったので、ラベルだけ定義して最後にリンクすれば大丈夫だと思ったんだけど、そうは行かなかった訳。やっぱり手抜きは良くないな。ちなみに、ROMデバッガのお蔭で原因を突き止めることができた。こう言う便利な物をROMに入れてくれてありがとね＞SHARPさん 1999/5/10 10:00 　連休中はまぁ～ったく手を手を付けてなかった。っても、サボっていた訳じゃなくて、ロングツーリングに行ってただけである。しばらく寝かせたので、例のバグは小人さん（笑）が直してくれているかと思ったんだけど、そんなに甘くなかったらしい。ん～～～。なにが悪いんだろう？？？ 1999/4/25 1:18 　なんだか低レベル関数郡を関数毎に分けてライブラリ化したら動かなくなってしまった(;_;)それも、どうやらローダー部分で動かなくなっているらしい（爆）原因が判らんなぁ～～～。怪しいと言えばヒープ関係の関数が、よりメモリー効率の良い物に置き換えたので、これかもしれなひ。どっちにしろ、続きは連休明けてからだな。 1999/4/24 7:20 　ソースとかが結構増えてきたので、ディレクトリィ・ツリーを整理した。ついでにローダーやカーネルで使っている低レベルライブラリも統合した。あと、FLOAT2もver.2.01のラベルを参考にしたので比較的簡単にver.2.03の解析も終わったし、ドライバにしちゃおっかな～～。 1999/4/23 6:30 　エラーの発生原因はどうやら、スタック領域の問題だったらしい。取り敢えずタスクを全てスーパーバイザーモードで動かすことで解決。ただし、ユーザーモードで動かすことを考えると、スーパーバイザースタックの扱いは注意せねば。　なにはともあれ、色々適当に処理しているところはあるものの、もっとも基本的なタスク処理は動くようになったと言う事で、嬉しいなっと。 1999/4/22 1:17 　「エラーが発生しました」状態が続いてちょっと手詰りなので、例外割り込み周りを付けてみた。場所自体は判るようになったけど、原因の方はさっぱり(;_;) やっぱり、逆アセンブル表示位は出来ないと原因追求は難しいか・・・「今回の実装コール」 get_pid() 1999/4/14 5:11 　また夜が開けてしまった・・・。それはともかく、最低限のタスク起動コールを実装した。タスクの切り替え自体もなんとなく動いているような気もするが、ちょっち自信無し（笑）。　あと、取り合えずの処置としてpget_blk()とrel_blk()も実装してある。ヒープ自体を生成するコールが無いので、グローバルヒープしか扱えないけど、これでしばらくはもつはずだ。　FLOAT2についてだが、disって解析していたのが実は古いバージョンで有ったのが判明（涙）。なんと、ver.2.01だったのだ。手持ちで一番新しいのはver.2.03 なので、もう一度解析せねば・・・(;_;) 「今回の実装コール」 cre_tsk() del_tsk() sta_tsk() slp_tsk() pget_blk() rel_blk() 1999/4/12 4:48 　よっしゃー！！システムコール第一号の実装が完了。動作もおっけー。とは言ってもget_ver()のみじゃタスクの切り替えもクソも無いので動いた内に入らないかも。　まぁ、タスクからのシステムコールで、カーネル内のCで書かれた処理関数までの引き数の引き渡しに付いて確認出来たのは間違いないので、やっぱりメデタイぞ。　FLOAT2.drvの作成だが、カーネルの作成が順調なので、ローダーに組み込むのはやめて、いきなりタスクにしちゃおっかなー。とか考えている。元になるFLOAT2.x自体は既にdisってあり、Human固有部分を外せばそのまま行けそうなので・・・「今回の実装コール」 get_ver() 1999/4/10 6:10 うひひ。ちょ～～～～～～～～～恥ずかしいバグを発見。これで、先日のシステムコールで止まってしまう問題は解決してしまった。なにが問題だったかは、恥ずかしすぎるので、闇に葬る事にしよう。なにはともあれめでたしめでたし。 1999/3/28 1:37 　なんとか、カーネルを読み込んで初期化出来るところまでたどり着いた。んが、システムコールはやっぱり１つとして組み込まれてない。　どのコールを呼び出してもエラーしか帰らないようになってるのだが、このダミー処理内で文字列を画面に表示(B_PRINT()で)しようとしたらエラーになってしまった(;_;) カーネルスタックの切り替えに失敗しているのだろうか？ 1999/3/18 0:20 　ついにカーネルの実行ファイルが出来た。ただし、システムコールは一切サポートしてないNULLカーネルだけど。それにしても、足りない物が随分あるなぁ（笑） ☆思い付くまま残件・ローダー　・カーネルの幾つかのシステムコールが動かないと、必須サーバーが登録出来　　ないので、ローダーの開発が進まない・・・・FLOAT?.xの解析　・取り敢えずFLOAT2.xをローダーに組み込んでおけば、ローダーが常駐してい　　る限りFEコールは使用可能になるな。ふふふ。　・そのうち、FLOAT2.xからFLOAT2.drvを作らねば・・・・BOOT_INFOに載せる情報。　・カスタマイズ可能な項目・メモリー管理方法　・全てグローバルヒープで行う？　・カーネルオブジェクトの管理には専用の固定長メモリー管理を使う？　・タスク用のローカルヒープも持たせる？・スレッドの実現　・EXECサーバーで管理する？　・カーネルでサポートする？　　・sta_tsk()で小細工する？　・タスク自体が軽いので不要？・OSの構成　・カーネル　・FLOATドライバ　・EXECサーバー　・NAMEサーバー　・FATサーバー　・CONSOLEサーバー　・FDドライバ　・TEXTドライバ　・KEYBOARDドライバ　・RAMDISKドライバ　・シェル 1999/2/16 　ローダースクリプトを解析して内部リストを構成することに成功。まだ、Human上でのテスト実行ではあるけど、IOCSコールを使用してのHumanファイルのアクセスまでたどり着けたわけだ。 1999/1/1 　何を思ったか、PECLS OSの開発を始める。とは言ってもいきなり動く物は何もないので、幾つかのディレクトリィを準備して、Makefileを書いて、使えそうなライブラリソースをかき集めただけ。でも、おそらくは長い開発の始まりなのは確かなのだ。ほんとは、決めておかないといけないことが一杯有る訳だけど、そう言った細かいことの覚え書きのために、この開発記を書き始めることにした。　たぶん、絶対に不定期になるので日記じゃ無くて開発記である。お間違えの無いように（笑）